src/coreclr/vm/stublink.cpp:564

• PerfMap::LogStubs now requires MODE_PREEMPTIVE (see perfmap.cpp contract), but this call site doesn't enforce preemptive mode. In contract-enabled builds this risks a contract assert if Link() is entered while cooperative. Consider switching to preemptive just for the logging call (and optionally guarding by PerfMap::IsEnabled() to avoid unnecessary mode transitions when disabled).
  src/coreclr/vm/threads.cpp:1047
• PerfMap::LogStubs requires MODE_PREEMPTIVE, but this call is currently made without an explicit preemptive transition. If InitThreadManagerPerfMapData runs in cooperative mode (common during initialization paths), this can trip contracts. Switching to preemptive just for the log call keeps the new PerfMap contracts honest.
  src/coreclr/vm/prestub.cpp:374
• PerfMap::LogPreCompiledMethod is now reachable even when FEATURE_PERFMAP is not defined, and it requires MODE_PREEMPTIVE. This call site doesn't explicitly switch to preemptive, which can cause contract asserts if PrepareCode runs in cooperative mode. Consider switching to preemptive just around the log call (and optionally guard by PerfMap::IsEnabled()).
  src/coreclr/vm/prestub.cpp:926
• PerfMap::LogJITCompiledMethod requires MODE_PREEMPTIVE, but this call site doesn't explicitly ensure preemptive mode. Switching to preemptive just for the log call keeps PerfMap contracts valid and avoids contract asserts when this code runs in cooperative mode.
  src/coreclr/System.Private.CoreLib/src/System/RuntimeHandles.cs:981
• IRuntimeMethodInfo.GetValue now depends on a layout contract ("m_value at the same offset" across all implementers) and uses Unsafe.As(method) to read it. This is brittle and can silently break if field layouts change (e.g., new fields, different field packing rules, different runtimes). Consider reverting to an explicit interface member (as before) or otherwise adding a strong, debug-time validation of the assumed layout/offsets so layout drift fails fast.

    internal interface IRuntimeMethodInfo
    {
        internal static RuntimeMethodHandleInternal GetValue(IRuntimeMethodInfo method)
        {
            // All implementations of IRuntimeMethodInfo are required to have a m_value field at the same offset as RuntimeMethodInfoStub.m_value.
            return new RuntimeMethodHandleInternal(Unsafe.As<RuntimeMethodInfoStub>(method).m_value);
        }

src/coreclr/vm/comdelegate.cpp:1177

• BindToMethodDetails is an out-parameter for a QCall, but this method doesn’t initialize all fields on every path. In particular, the closed-delegate path never assigns methodPtrAux (and extraData/loaderAllocatorGCHandle are set later), which can leave managed code reading uninitialized data from the out struct. Initialize the struct fields up front (at least methodPtrAux) so every field has a deterministic value regardless of which branch is taken.

    pTargetMethod->EnsureActive();

    if (fIsOpenDelegate)

src/coreclr/vm/comdelegate.cpp:1675

• Delegate_Construct returns BindToMethodDetails via an out struct, but the closed-delegate branch never assigns methodPtrAux. Managed code always copies methodPtrAux into the delegate instance, so this can propagate an uninitialized pointer. Initialize methodPtrAux (and other fields) before branching so the out struct is fully defined for both open and closed delegates.

    // If the loader allocator is not collectible, this will be NULL
    pBindToMethodDetails->loaderAllocatorGCHandle = pMeth->GetLoaderAllocator()->GetLoaderAllocatorObjectHandle();

    // Open delegates.
    if (invokeArgCount == methodArgCount)

src/coreclr/vm/stublink.cpp:564

• PerfMap::LogStubs now has a MODE_PREEMPTIVE contract, but StubLinker::Link doesn’t establish preemptive mode (STANDARD_VM_CONTRACT only declares THROWS). This risks contract violations in debug builds and undermines the goal of keeping PerfMap interactions preemptive-only. Wrap the log call in a preemptive-mode scope (or update the function contract accordingly).

src/coreclr/System.Private.CoreLib/src/System/RuntimeHandles.cs:981

• IRuntimeMethodInfo.GetValue relies on Unsafe.As(method) and a presumed field-offset/layout agreement across all implementors. That assumption is not enforced by the type system and can silently break if any IRuntimeMethodInfo implementor changes its field layout (or if a new implementor is added), leading to incorrect handles and hard-to-debug failures.

Consider restoring a real interface member (e.g., RuntimeMethodHandleInternal Value { get; }) with explicit implementations, or otherwise providing a type-safe mechanism to extract the handle without depending on object layout.

    internal interface IRuntimeMethodInfo
    {
        internal static RuntimeMethodHandleInternal GetValue(IRuntimeMethodInfo method)
        {
            // All implementations of IRuntimeMethodInfo are required to have a m_value field at the same offset as RuntimeMethodInfoStub.m_value.
            return new RuntimeMethodHandleInternal(Unsafe.As<RuntimeMethodInfoStub>(method).m_value);
        }

src/coreclr/vm/comdelegate.cpp:1178

• BindToMethodDetails is an out struct returned to managed code, but COMDelegate::BindToMethod does not initialize all fields on the closed-delegate path (e.g., methodPtrAux is never assigned). This can propagate uninitialized stack garbage into Delegate._methodPtrAux when the QCall succeeds, causing unpredictable crashes. Consider zero-initializing the struct at the start of the method (and ideally add a PRECONDITION for pBindToMethodDetails).
  src/coreclr/vm/comdelegate.cpp:1635
• Delegate_Construct returns BindToMethodDetails via an out parameter, but the closed-delegate path never assigns methodPtrAux. Since managed code always copies bindToMethodDetails.methodPtrAux into Delegate._methodPtrAux on success, leaving this field uninitialized can corrupt the delegate instance. Zero-initialize *pBindToMethodDetails early in the QCall so all fields have defined defaults.

src/coreclr/vm/stublink.cpp:565

• PerfMap::LogStubs now has a MODE_PREEMPTIVE contract, but StubLinker::Link is under STANDARD_VM_CONTRACT and doesn't ensure preemptive mode before calling it. This will trip contracts in checked builds if Link is entered in cooperative mode (and it’s also inconsistent with the PR goal of only calling PerfMap in preemptive). Wrap the LogStubs call in a GCX_PREEMP() scope.
  src/coreclr/vm/amd64/cgenamd64.cpp:612
• BEGIN_DYNAMIC_HELPER_EMIT calls PerfMap::LogStubs, which now requires MODE_PREEMPTIVE. The macro expansion doesn't ensure preemptive mode, so any cooperative callers will violate contracts. Consider wrapping the LogStubs call in a GCX_PREEMP() scope inside the macro (and apply the same pattern to the other architecture helper emit macros).

#define BEGIN_DYNAMIC_HELPER_EMIT(size) \
    BEGIN_DYNAMIC_HELPER_EMIT_WORKER(size) \
    PerfMap::LogStubs(__FUNCTION__, "DynamicHelper", (PCODE)p, size, PerfMapStubType::Individual);

src/coreclr/vm/i386/cgenx86.cpp:568

• Same issue as amd64: BEGIN_DYNAMIC_HELPER_EMIT calls PerfMap::LogStubs (MODE_PREEMPTIVE) without ensuring preemptive mode first. Wrap the LogStubs call in GCX_PREEMP() within the macro to keep contracts consistent.

src/coreclr/vm/comdelegate.cpp:1176

• COMDelegate::BindToMethod returns BindToMethodDetails to managed code, but the struct isn’t fully initialized on all paths (notably methodPtrAux in the closed-delegate case). Since the managed caller always assigns _methodPtrAux from this struct, any uninitialized field can turn into delegate state corruption.

Suggestion: zero-initialize the out struct at the start of the function, then overwrite fields as needed in the open/closed branches.
src/coreclr/vm/comdelegate.cpp:1673

• Delegate_Construct populates BindToMethodDetails for managed code to apply onto the delegate instance, but methodPtrAux isn’t written on the closed-delegate path. Since the managed side always assigns _methodPtrAux from this struct, leaving it uninitialized can corrupt delegate state.

Recommendation: initialize the out struct fields to known defaults before the open/closed delegate branches.
src/coreclr/System.Private.CoreLib/src/System/RuntimeHandles.cs:981

• IRuntimeMethodInfo.GetValue relies on Unsafe.As<RuntimeMethodInfoStub>(method) and a comment-level contract that all IRuntimeMethodInfo implementations have an IntPtr field at the same offset as RuntimeMethodInfoStub.m_value. This is a very brittle invariant: it’s not enforced by the type system, and any future IRuntimeMethodInfo implementer (or layout change in existing ones) could silently return the wrong handle and cause hard-to-debug runtime corruption.

If the goal is to avoid calling into managed code from preemptive regions, consider using an explicit interface member again (even if it’s just a trivial field return) or otherwise enforce/validate this layout coupling in one place rather than depending on Unsafe.As across unrelated types.

    internal interface IRuntimeMethodInfo
    {
        internal static RuntimeMethodHandleInternal GetValue(IRuntimeMethodInfo method)
        {
            // All implementations of IRuntimeMethodInfo are required to have a m_value field at the same offset as RuntimeMethodInfoStub.m_value.
            return new RuntimeMethodHandleInternal(Unsafe.As<RuntimeMethodInfoStub>(method).m_value);
        }